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(57) The present invention relates to navigation of 
the Internet by a two-way interactive communication 
mobile device capable of wireless communication, via 
a link server (300), with service providers or network 
servers on the Internet. After the mobile device has es- 
tablished a communication session with the link server 
over a wireless network (308), a control engine 320 in 
the link server is initiated and uses the computing re- 
sources of the link server device so as to be responsible 
for tasks that require considerable computing powe r and 
memory, such as processing of URL requests, interpre- 



tation of markup language files, management of data 
cache and variable states. Working with a message 
processor (315) in the sender device, the control engine 
communicates with an interface engine in the mobile de- 
vice using a compact data format that is efficiently trans- 
portable in the wireless data network. The interface en- 
gine typically performs tasks that do not require consid- 
erable computing power and memory, such as receiving 
input data from users, and the rendering of the compact 
data format received from the link server device, to 
cause the mobile device to display contents in the 
markup language files on a display screen. 
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Description 

CROSS-REFERENCE TO RELATED APPLICATION 

[0001] This application is a continuation-in-part of 
pending U. S. Patent Application No. 08/570, 21 0 entitled 
'METHOD AND ARCHITECTURE FOR AN INTERAC- 
TIVE TWO-WAY DATA COMMUNICATION NET- 
WORK" by Alain Rossmann. one of the co-inventors 
hereof. 

AUTHORIZATION WITH RESPECT TO COPYRIGHTS 

[0002] A portion of the present disclosure contains 
material subject lo copyright protection. Such material 
includes, but is not limited to, an Appendix entitled "Imp 
Specification protocols between Femto Engine and Ter- 
minal". The copyright owner has no objection to the fac- 
simile reproduction by anyone of the patent document 
or the patent disclosure, as it appears in the Patent and 
Trademark Office patent files or records, but othenvise 
reserves ail copyright rights whatsoever. 

BACKGROUND OF THE INVENTION 

Field of the Invention 

[0003] This invention relates generally to data com- 
munications, and in particular to interactive two-way 
communication mobile devices that permit a user to in- 
teract with a network server providing hypermedia infor- 
mation through a data network. Such a data network can 
include, for example, the Internet and a wireless net- 
work. The mobile devices may include cellular tele- 
phones, a two-way pagers, or a palm-sized computing 
devices and typically have limited computing resources. 

Description of the Related Art 

[0004] The Internet is a rapidly growing communica- 
tion network of interconnected computers and computer 
networks around the world. Together, these connected 
computers form a vast repository of multimedia informa- 
tion that is readily accessible by the connected comput- 
ers from anywhere at any lime. To navigate a portion of 
the Internet organized as the "World Wide Web", the 
connected computers, e.g., workstations and desktop 
computers, typically utilize a user interface called a 
"browser". A browser is a client application program that 
generally requests multimedia information residing on 
the Internet using, typically, the Hypertext Transfer Pro- 
tocol (HTTP). A computer which operates a browser us- 
ing HTTP is generally a relatively powerful computer 
with sufficient computing resources, such as processing 
power, memory, a display capability and a user inter- 
face. 

[0005] To provide mobility and portability of access to 
the Internet, interactive two-way communication mobile 



devices capable of communicating, via wireless data 
networks, with the Internet have been introduced. The 
interactive two-way communication mobile devices (e. 
g.. two-way pagers, cellular phones, palm-sized com- 
5 puting devices and personal digital assistants (PDAs)) 
■ are among the fastest emerging communication devic- 
es. These devices enable users to receive, collect, an- 
alyse, review and disseminate information as the users 
travel or nrtove about. Unlike computers coupled to the 

10 Internet, the mobile devices are characterized by severe 
limitations in computing resources. For example, a cel- 
lular phone has less than one percent of the processing 
power of a typical desktop personal computer, generally 
less than 128 kilobytes of memory, an LCD display 

15 which is perhaps four lines high by twelve or twenty 
characters, and limited or non-existent graphics capa- 
bilities. Further, a cellular phone inputs data using a key- 
pad that has far fewer keys than a typical personal com- 
puter (PC) keyboard.. With these constraints, a mobile 

20 device cannot efficiently operate the browser used by 
desktop computers to navigate the Internet. 
[0006] To make available to mobile devices comput- 
ing resources comparable to a desktop computer is too 
costly. There is, therefore, a great need for a solution 
25 that enables mobile devices tof reely access information 
on the Internet without providing these computing re- 
sources in the mobile device. 

[0007] Additionally, mobile devices are typically serv- 
iced through one or more wireless service carriers. The 

30 wireless sen^ice carriers often provide additional serv- 
ices by upgrading client application programs in the mo- 
bile devices. In conventional computers, an upgrade 
can be accomplished by downloading a new version of 
an application program from a service provider. In mo- 

35 bile devices, downloading a new version of an applica- 
tion program can be a prohibitively inefficient task, lim- 
ited by the performances of the computing resources 
and the wireless network. Hence, there is further need 
for an ability to manage client application programs op- 

40 erated by the mobile devices. 

SUMMARY OF THE INVENTION 

[0008] The present invention addresses the above 
45 described problems and is particularly applicable to en- 
abling navigation of Internet web pages by two-way in- 
teractive communication mobile devices (e.g., mobile 
computing devices, cellular phones, palm-sized compu- 
ter devices, personal digital assistant devices and Inter- 
ne net- capable appliance remote controllers) which are ca- 
pable of wireless communication via a link server with 
service providers or network servers on the Internet. De- 
spite the common deficiencies of mobile devices (i.e., a 
primitive processor, littio memory and limited graphics 
55 capability) which make rt economically and technically 
impractical for the mobile devices to operate a local 
browser functioning as if it was in a desktop computer, 
the present invention allows the mobile devices to inter- 
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act effectively with the Internet and can be used with a 
wide variety of wireless communication networks (e.g., 
cellular digital packet data (CDPD) network. Global Sys- 
tem for Mobile Communications (GSM) network, Code 
Division Multiple Access (CDMA) network and Time Di- 
vision Multiple Access (TDMA) network). 
[0009] According to one aspect of the present inven- 
tion, a mobile device includes an interface engine that, 
via a client module, communicates and operates with a 
control engine in a link server device over a wireless net- 
work. The control engine, which utilizes the computing 
resources of the link server device, is responsible for 
tasks that require considerable computing power and 
memory, such as processing of URL requests, interpre- 
tation of markup language files, management of data 
cache and variable states. Further, working with a mes- 
sage processor In the server device, the control engine 
communicates with an interface engine using a compact 
data format that is efficiently transportable in the wire- 
less data network. The interface engine typically per- 
forms tasks that do not require considerable computing 
power and memory, such as receiving input data from 
users, and the rendering of the compact data format re- 
ceived from the link server device, to cause the mobile 
device to display contents In the markup language files 
on a display screen. 

{001 0] According to another aspect of the present in- 
vention, incoming messages to the mobile device, in- 
cluding notification and requests, and which typically 
has one or more universal resource identifiers or loca- 
tors, are processed in the link server device to generate 
compact messages. The link server device replaces uni- 
versal resource locators in the incoming message with 
address identifiers, and manages an address table 
mapping each universal resource locator with an ad- 
dress Identifier. Thus processed, the resulting compact 
messages demand less bandwidth of the wireless net- 
work, thus reducing high latency and requiring less air 
time. 

[001 1] According to still another aspect of the present 
Invention, local service requests in the mobile device are 
processed simultaneously in the Interlace engine and 
the control engine. In the prior art, all local service re- 
quests are processed locally at the terminal where the 
local services are requested. The computing devices of 
the prior art, such as personal computers and worksta- 
tions, can process local requests because of their com- 
puting power, memory and display capabilities. The mo- 
bile devices in the present invention, however, taking 
advantage of a cooperation between the interface en- 
gine and the control engine over the wireless network, 
services the requests with the limited computing re- 
sources of the mobile devices and without significantly 
compromising overall performance. 
[0012] Thus, unlike the closed and proprietary prior 
art mobile devices (e.g., mobile phones and two-way 
pagers), the present invention allows thinly designed 
mobile devices to become open application platforms. 



Such an open application platform allows software de- 
velopers to develop value-added applications and serv- 
ices to these thinly designed mobile devices. Conse- 
quently, many more new uses can be developed for two- 
5 way communication mobile devices and two-way com- 
munication networks, including wireless networks, with- 
out physical modification or addition to the two-way 
communication mobile device. 

[0013] The present invention can be Implemented In 

10 numerous ways. For example, according to one embod- 
iment of this invention, a method of the present invention 
allows an Interactive two-way communication mobile 
device with a display screen to interact with a network 
server. In this method, a control engine in a link server 

15 is initiated when the mobile device establishes a com- 
munication session with the link server. (Such a link 
server couples the network server of a landnet, which 
uses a first communication protocol, to a wireless net- 
work which uses a second communication protocol.) 

20 The link server Includes: (a) an account manager man- 
aging a user account associated with the mobile device; 
and (b) a message processor receiving a message from 
the network server over the landnet. Upon initiation, the 
control engine communicates with an interface engine 

25 of the mobile device corresponding to the user account, 
and converts the message, using the message proces- 
sor, to a compact data file that can be efficiently trans- 
portable In the wireless network. 

[0014] According to another embodiment of this in- 

30 vention. In a method of the present invention, the link 
server sends over the wireless network a compact data 
file it generates, and the interface engine renders the 
compact data file to cause the display screen to display . 
according to the content of the compact data file. 

35 [0015] According to still another embodiment of this 
invention, a system of the present invention includes: 
(a) a memory for storing code for a server module; (b) 
a data storage device for maintaining a user account for 
the mobile device; and (c) a processor coupled to the 

40 memory and the data storage device. The processor ex- 
ecutes the code In the memory to cause the server mod- 
ule to; (a) execute a control engine associated with an 
interface engine of a mobile device; (b) receive a net- 
work message from the network server over the landnet, 

45 using a first communication protocol; (c) buffer the net- 
work message In a cache memory; (d) generate a com- 
pact message from the network message; and (e) send 
the compact message to the mobile device over the 
wireless network, using a second communication proto- 

so col. 

[0016] According to still another embodiment of this 
invention, a system of the present invention includes: 
(a) a display screen; (b) an input moans; (c) a memory 
for storing code for a client module; and (d) a processor 
55 coupled to the memory and controlling the display 
screen and the input means. The processor executes 
code in the memory to cause the client module to: (a) 
execute an interface engine when activating a prede- 
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fined key; (b) maintain the interface engine to work with 
a control engine operating in the link server device in 
concert; (c) receive a compact message from the link 
server device over a wireless network, wherein the com- 
pact message is generated by a message processor in 
the link server device according to a network message 
received from the network server over a landnet; and 
(d) render the compact message to cause the display 
screen to display contents in the network message. 
[001 7] Accordingly, one of the objects of this invention i 
is to provide a generic solution to two-way communica- 
tion mobile devices with limited computing resources 
that can enable them to effectively interact with a land- 
net such as the Internet. 

[0018] Other objects, together with the foregoing are ' 
attained in the exercise of the invention in the following 
description and resulting in the embodiment illustrated 
In the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 2i 

[0019] The present invention will be readily under- 
stood by the following detailed description In conjunction 
with the accompanying drawings, wherein like reference 
numerals designate like structural elements, and in 2£ 
which:- 

Figure 1 illustrates a schematic configuration in 
which the present invention may be practised; 
Figure 2A depicts a block diagram of a typical GSM 30 
digital cellular phone that can be used in the data 
network of FIG. 1 to practice the present invention; 
Figure 2B illustrates an internal functional block di- 
agram of an exemplary digital cellular phone that 
may corresponds to the GSIVI digital cellular phone 35 
of Figure 2A; 

Figures 3A and SB illustrate functional block dia- 
grams of a link server device and a mobile device 
according to an embodiment of the present inven- 
tion; 40 
Figure 4 depicts an account structure used in the 
description of the present invention; 
Figures 5A and 58 illustrate respectively two exem- 
plary screen displays on a display screen of a mo- 
bile device; 45 
Figure 6 denr»onstrates an overview of a systematic 
configuration according to the present invention; 
Figures 7A to 7G illustrate a series of screen dis- 
plays to illustrate the navigation of the Internet 
through a mobile device according to the present so 
invention; 

Figure 8 A demonstrates an address table per de- 
vice to send an address identifier to an actual IP 
address over a wireless network; 

Figure SB demonstrates an address table managed ss 
by an account manager to maintain groups of ad- 
dress identifiers in a link server for all the mobile 
devices in communication with the link server; and 



Figures 9A and 9G illustrate a process flowchart of 
the present invention according to one embodi- 
ment. 

■ DETAILED DESCRIPTION OF THE INVENTION 

[0020] Referring now to the drawings, in which like nu- 
merals refer to like parts throughout the several views. 
Figure 1 illustrates a schemata configuration in which 
' the present invention nnay be practised. As shown in Fig- 
ure 1 , landnet 100 is a land-based network that may be 
the Internet, an intranet or a data network of any private 
network. Coupled to landnet 1 00 are a personal compu- 
ter (PC) 110 and a network server 104. Personal com- 
puter 1 1 0 may be a Pentium 1 1 -based desktop personal 
computer. Preferably, personal computer 110 runs a Hy- 
perText Markup Language (HTML) browser, such as 
Netscape Navigator from Netscape Communications 
Corporation (http://www.netscape.com) via landnet 100 
using HyperText Transfer Protocol (HTTP) to access in- 
formation stored in network server 1 04. which may be 
a workstation from SUN Microsystems Inc (http://www. 
sun.com/). The information stored in network server 104 
may be hypermedia information including mobile data 
designed for mobile devices. 

[0021] There are n mobile devices 106 serviced by 
airnet 102. Mobile devices 106 are interactive two-way 
communication devices (e.g., mobile computing devic- 
es, cellular phones, palm-sized computing devices with 
PDA (Personal Data Assistants) functionality and Inter- 
net-capable appliance remote controllers) which are ca- 
pable of communicating wirelessly with antenna 1 08 via 
airnet 102. As shown, antenna 108 also represents a 
wireless carrier infrastructure that generally includes a 
base station and an operations and maintenance center. 
The base station controls radio or telecommunication 
links with mobile devices 106. The operations and main- 
tenance center comprises a mobile switching center 
performing the switching of calls between the mobile de- 
vices and other fixed or mobile network users. Further 
the operations and maintenance center manages mo- 
bile account sen/ices, such as authentication, and over- 
sees the proper operation and setup of the wireless net- 
work. Each of the hardware components and processes 
in carrier infrastructure 108 are known to those skilled 
in the art and thus are not described here to avoid un- 
necessarily obscuring aspects of the present inventk>n. 
[0022] Between landnet 1 00 and airnet 1 02 there is a 
link server device 114 functioning as a bridge between 
the two networks 100 and 102. Link server device 114, 
which is also referred to as proxy server or wireless data 
server or network gateway server, may be a workstation 
or a personal computer. Link server 114, which is loaded 
with many processes including compiled and linked ver- 
sions implementing the present invention, couples air- 
net 102 to landnet 100 and performs many functions as 
described in more detail below. One of the functions that 
link server 114 performs is to facilitate the communica- 
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tion of mobile devices 106 with any of the devices cou- 
pled to landnet 100, including mapping or translating 
fronn one communication protocol in landnet 100 to an- 
other in airnet 1 02 or vice versa. 

[0023] To facilitate the description of the present in- 
vention, Figure 2A depicts a typical GSM digital cellular 
phone 200 that can be used as one of the mobile devices 
106 in the arrangement of Figure 1 to practice the 
present invention. Cellular phone 200 includes a small 
screen 202 and an extended phone keypad 204. Screen 
202 is typically a LCD display capable of displaying per- 
haps four lines high by twelve or twenty characters with 
limited graphics capabilities. Extended phone keypad 
204 includes, preferably, a regular phone keypad 206, 
a pair of generic keys 208 and 210 and positioning key 
212. Generic keys 208 and 210 are used to activate soft 
keys displayed in screen 202 and position ingkey2 12 is 
to reposition an element indicator or a cursor to activate, 
for example, one of the hyperlinks displayed in screen 
202. Generic keys 208 and 210 and positioning key 212 
are not necessary in practising the present invention. 
These keys can be replaced by a set of designated keys 
in regular phone keypad 206 but provide preferred con- 
venient means for a user to interact efficiently with the 
phone 200. Further, having a regular phone keypad Is 
not a requirement to practice the present Invention. 
Some of the mobile devices have no physical keys at 
all, such as those palm-size computing devices that use 
"soft keys" or icons for receiving user Input data. In the 
following, unless otherwise specifically described, keys 
or buttons are generally referred to as either physical 
keys or soft keys. 

[0024] Figure 2B illustrates a functional block diagram 
of digital cellular phone 200. Since each of the hardware 
components in digital cellular phone 200 is known to 
those skilled in the art, the hardware components are 
not described in detail. Besides keypad circuit 246 for 
keypad 204 and display drive 248 for display screen 
202, the main components in digital cellular phone 200 
also include a random access memory (RAM), a read- 
only memory (ROM) and a physical layer processor or 
microcontroller 128. According to one embodiment, 
compiled and linked processes of the present invention 
are stored In ROM 250 as a client module 252 and a 
support module 254. Upon activation of a predeter- 
mined key sequence utilizing keypad 204, physical layer 
processor 128 causes client module 252 to communi- 
cate with link server 114 of Figure 1 via a radio trans- 
ceiver 256. 

[0025] It is generally understood that a computing de- 
vice equipped with an HTML browser using HTTP can 
access hypermedia Information in a network server. 
However, HTTP requires considerable computing pow- 
er and network bandwidth resources. For example, a re- 
quest from a computing device to establish a communi- 
cation session with a network server may require an ex- 
change of a number of data packets. In addition to the 
resources required to Implement HTTP, significant re- 



sources must be supported In the computing device to 
request, format, process and display Information. This 
is not a significant disadvantage In many situations be- 
cause the computing device, including personal com- 
5 puters and workstations coupled to a network operating 
HTTP, generally has sufficient computing power, mem- 
ory and display capabilities. 

[0026] Nevertheless, cellular phone 200 or mobile de- 
vices 1 06 of Figure 1 typically do not have the computing 
io resources to implement HTTP to run an HTML. browser 
The computing power In cellular phone 200 or mobile 
devices 106 of 

[0027] Figure 1 is typically less than one percent of a 
laptop personal computer's computing power, the mem- 

15 ory capacity is generally less than 1 28 kilobytes and the 
graphics display capability is very limited. Cellular 
phone 200 or any of mobile devices 106 of Figure 1 is 
not a replacement of a desktop computing device or the 
combination of a wireless communication module and a 

20 personal computer. Further, making a mobile device, 
such as cellular phone 200, capable of navigating hy- 
permedia information in a network server is a significant 
departure from prior art systems. 

[0028] Referring now to Figures 3A and 3B, there are 

^5 respectively shown functional block diagrams of a link 
server device and a mobile device according to an em- 
bodiment of the present invention. Link server device, 
or simply link server 300, that may represent link server 
102 of Figure 1 , Is typically a server computer Mobile 

30 device 350 may, for example, correspond to one of mo- 
bile devices 106 of Figure 1 or cellular phone 200 of Fig- 
ure 2. To avoid obscuring any aspect of the present in- 
vention, well known methods, procedures, components 
and circuitry in link server 300 and mobile device 350 

35 are not described In detail. 

[0029] Link server 300 includes a landnet communi- 
cation protocol (LCP) Interface 302 that couples to land- 
net 304, and a wireless communication protocol (WCP) 
Interface 306 that couples to a wireless network 308 via 
a carrier's infrastructure (not shown in the figure). LCP 
interface 302 Implements a communication protocol op- 
erated in landnet 304. Generally, landnet 304 operates 
HTTP, so that LCP interface 302 is typically an HTTP 
interface. Similarly, wireless network 308 may operate 

45 a wireless communication protocol suitable for the char- 
acteristics of a wireless network. One of the available 
wireless communication protocols is Handheld Device 
Transport Protocol (HDTP) "(formerly known as Secure 
Uplink Gateway Protocol (SUGP)), which runs on User 

50 Datagram Protocol (UDP). In this embodiment, WCP in- 
terface 306 Is implemented with a UDP or HDTP Inter- 
face. HDTP Is developed by Unwired Planet (Phone, 
com) Inc. located at 800 Chesapeake Drive, Redwood 
City, CA 94053. The specifications of HDTP, entitled 

55 "HDTP Specification" is enclosed and Incorporated 
herein by reference in its entirety. 
[0030] To facilitate the description of the present in- 
vention, the wireless communication protocol in use is 
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HDTP The present invention is. however, not limited by 
this exemplary communication protocol. 
[0031] HDTP is a session-level protocol that resem- 
bles HTTP but runs on UDP and without incurring the 
overhead of HTTP/TCP and is highly optimized for use 
in thin devices, such as the mobile devices, that have 
significantly less computing power and memory than 
those of a desktop personal computer. Further, UDP 
does not require a connection to be established be- 
tween a client device and a sen/er before information 
can be exchanged, which eliminates the need of ex- 
changing a large number of packets during a session 
creation. Exchanging a very small number of packets 
during a transaction is one of the desired features for a 
mobile device with limited computing power and mem- 
ory to effectively interact with a landline device. 
[0032] Link server 300 further comprises a server 
module 310 coupled between LCP interface 302 and 
WCP Interface 306. Server module 310, which Is typi- 
cally loaded In a memory, performs traditional server 
processing as well as protocol conversion processing 
from one communication protocol to another communi- 
cation protocol. In particular, the protocol conversion 
processing Includes protocol conversion between 
HDTP/UDP and HTTP/TCP according to one embodi- 
ment. 

[0033] In server module 310, account manager 312 
manages through account interface 31 4 a number of us- 
er accounts for all the mobile devices serviced by link 
server 300. Each of the mobile devices, such as 350, Is 
assigned a device identification (ID). Device ID can be 
a phone number of the device or an IP address or a com- 
bination of an IP address and a port number, for exam- 
ple; 204.163.165.132:01 905 where 204. 163. 165. 132 is 
the IP address and 01 905 is the port number. Thedevice 
I D is further associated with a subscriber I D created and 
administrated by a carrier in link server 300 as part of 
the procedures to activate a subscriber account for mo- 
bile device 350. The subscriber ID may take the form of, 
for example, 861 234567-1 0900_pn.mobile.att. net by 
AT&T Wireless Service, and Is a unique Identification to 
a mobile device. In other words, each of nrxjbite devices 
106 serviced by link sen/er 114 In Figure 1 has a unique 
device ID that corresponds to a respective user account 
In link server 114. Additionally, account manager 312 is 
responsible for creating a user account for a mobile de- 
vice that anonymously communicates with link server 
114. In this case, account manager 312 ensures proper 
(limited) access of the anonymous mobile device to 
services provided by link server 114. 
[0034] Figure 4 shows an exemplary structure 400 of 
the user accounts managed by account manager 312. 
It should be noted that the user accounts need not be 
physically tocated In link server 300. In fact, the user 
accounts can be remotely kx;ated in one of the comput- 
Ing devices coupled to the landnet 104. Through ac- 
count interface 314 that has proper and secure access 
tothe user accounts, account manager 31 2 can conduct 



the duties of account management, as discussed In fur- 
ther detail below. Device ID column 402 Is filled with the 
device IDs of mobile devices that correspond to sub- 
scriber IDs in subscriber ID column 404. Credential in- 
formation column 406 lists credential information need- 
ed to access each associated account. User info 408 
may include the account configuration information, for 
example, device ID "6508171453' is a mobile phone 
that is pre- configured to work in a CDPD network and. 
probably, may be provided with an option to switch to a 
GSM network If necessary. Further entries in user Info 
column 408 may include pointers or linkages 41 0 to oth- 
er account-related Information, such as system param- 
eters, encryption schemes, call plan and customer serv- 
ice information that can be accessed by the mobile de- 
vice. 

[0035] Returning now to Figures 3A and 3B, a data- 
base of user accounts permits account manager 31 2 to 
authenticate and to verify the subscribed mobile devices 
and to control access to provided services by all mobile 
devices (subscribed or anonymous devices) via wire- 
less data network 308. More importantly in the present 
invention, account manager 312 is responsible for man- 
aging the operations of control engines 320, which are 
respectively and independently associated with one mo- 
bile device. The detailed operations of control engines 
320 are provided below. 

[0036] The following description is focussed on mo- 
bile device 350 and its associated account. However, 
the present description is equally applicable to any mo- 
bile device in communication with link server 300. 
[0037] In addition, server module 310 includes mes- 
sage processor 315, which includes a message digester 
31 6 and a converter 31 8. Message processor 31 5 proc- 
35 esses messages communicated between a network 
server and link server 300 and generates for each mes- 
sage a corresponding compact message to be commu- 
nicated between link server 300 and mobile device 350. 
In particular, message digester 316 receives the mes- 
40 sages from the network server and performs a se- 
quence of message processing that Include interpreta- 
tion and management of the messages. Converter 318 
converts the messages, according to the interpretation, 
to a data format that Is compact enough to be optimally 
« efficiently transportable over wireless network 308. The 
messages received from the network server are typical- 
ly markup language files or data, requests, notifications 
and other commands that could cause mobile device 
350 to respond as desired in the received messages, 
w The markup language may include^ for example. Hand- 
held Device Markup Language (HDML), HyperText 
Markup Language (HTML), compact HTML, Wireless 
Markup Language (WML), Standard Generalized 
Markup Language (SGML) and Extensible Markup Lan- 
'>s guage (XML). 

[0038] For example. LCP Interface 302 receives an 
HDML file from a financial network server that directs 
mobile device 350 to display a pre-deslgned screen, in 
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response to mobile device 350*s request to the financial 
network server. The exerriplary HDML file is listed as 
follows: 

< HDML VERSION = 2.0 > 

<DISPLAY NAME > 

< ACTION TYPE = ACCEPT TASK = 
GO DEST = #card2> 

Dow has hit 20,000 today ! 
Nasdaq has popped 20%. 
Detailed Financial Headlines 
</DISPLAY > 
</HDML> 

[0039] The screen display corresponding to this 
HDML file is shown in Figure 5A. If a user selects the 
"OK" soft key, a list of the detailed financial news pack- 
aged in one or more HDML files would be fetched 
(pulled) from the financial network server and displayed, 
as shown in Figure 5B. As used herein, a display screen 
or screen is the physical display apparatus in a device, 
such as a 4 by 20 character LCD screen in a mobile 
device or 2.5 inch by 3.5 inch touch LCD screen in a 
palm-sized computer. A screen display is the image pre- 
sented on the display screen. As shown in Figure SB, 
display screen 500 shows a list of choices with element 
indicator 510 pointing to the first choice. Pointer 51 2 in- 
dicates that screen display 508 has more items to bo 
displayed but limited by the size of display screen 500. 
[0040] As described above, mobile device 350 typi- 
cally does not have the necessary computing power and 
memory to operate a browser in response to the HDML 
files. Therefore, an HDML file received is first analysed 
by message digester 316 and then converted through 
converter 31 8 into a set of screen commands that cause 
a mobile device, upon receiving the screen commands, 
to display the contents in the HDML file in response to 
the screen commands. Typically, the screen commands 
are expressed in a form of screen description data 
(SDD) that is rendered in an interface engine in mobile 
device 350. The following is an example of an SDD 
stream: 

c353 c836 e003 446f 7754 036B 6173 5803 6869 
74e0 0632 302c 

3030 3057 0574 6f64 6179 eOOl 21 52 0844 6574 
6169 6c65 64e0 

0946 696e6l6e 6369 616c e009 4865 6164 6c69 
6e65 73tf 

which is considerably smaller than the corresponding 
HDML file. The "ASCII-like' representation of the above 
illustrated SDD file is: 

type = screen seq-num - 54 

<WRAP> "Dow" offset=4 "has" offset=8 "hit" 

<WRAP> "20,000" offset = 7 "today* 

<WRAP> "I" offset = 2 "Detailed" 

<WRAP> "Financial" 

< WRAP> "Headlines" 

< end > 

Transmission of a smaller data file is important in wire- 
less data networks that are characterized with by low 



bandwidth and expensive airtime. According to one em- 
bodiment, the SDD file is a group of Imp data, the de- 
tailed specification of the Imp data is provided in the Ap- 
pendix entitled "Imp Specification protocols between 

5 Femto Engine and Terminal", which is hereby incorpo- 
rated by reference for all purposes in its entirety. There 
are a set of rules or grammars in the Imp data that an 
interface engine, upon rendering the Imp data, causes 
a screen to display the contents of the corresponding 

10 markup language file. 

[0041] In other words, the actual data being ex- 
changed between link server 300 and mobile device 350 
is in SDD format, which is typically binary and can be 
communicated more compactly and efficiently over 

15 wireless network 308. Further SDD files can be directly 
rendered by an interface engine in mobile device 350 
without further processing. Nevertheless, the above 
procedures are provided for illustrative purpose only 
and the present invention. is not limited by to the Imp 

20 data formal. According lo another embodiment, the 
message processor does not have a pair of separate 
message digester and converter, a markup language file 
in HDML, compact HTML or XML is received at the mes- 
sage processor and converted into a corresponding bi- 

25 nary file that is much smaller in size and may be in Imp, 
cHDML, cHTML, or cXML, wherein "c" means stripped, 
compressed, compiled or converted version of the cor- 
responding markup files. 

[0042] To interact with mobile device 350, server mod- 
30 ule 310 further includes control engine 320. Control en- 
gine 320 works in conjunction with an interface engine 
in nnobile device 350 and further with message proces- 
sor 315 to interpret actions from mobile device 350 in 
the present embodiment. More detailed description of 
35 the interactions between the interface engine in mobile 
device 350 and control engine 320 in server module 310 
are is given below. 

[0043] Mobile device 350 includes a corresponding 
WCP interface 352 that couples to airnet 308 via a RF 

^0 transceiver (not shown in the figure) to receive incoming 
and outgoing data signals. WCP interface 352 is imple- 
mented with a UDP interface, as is WCP interface 306, 
when wireless network 308 operates HDTR When an- 
other wireless communication protocol is operated in 

45 wireless network 308, both WCP interface 352 and 
WCP interface 306 are readily implemented accordingly 
so that link server 300 and mobile device 350 can com- 
municate with each other. 

[0044] Device Identifier (ID) storage 354 supplies a 
5o device ID to WCP interface 352. The device ID identifies 
a mobile device 350 and directly corresponds to the de- 
vice ID in the user account in link server 300. In addition, 
mobile device 350 includes a client module 356 that per- 
forms many of the processing tasks performed by the 
55 mobile device 350. Such processing tasks include es- 
tablishing a communication session with line server 300 
via carrier network 308, requesting and receiving data 
from carrier network 308. displaying information on a 
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display screen 360, and receiving user input data. Spe- 
cifically, client module 356 Is coupled to WCP interface 
352 to establish a connmunication session and to re- 
quest and receive data. Additionally. Client module 356 
operates, among other things, an interface engine 364 
that typically receives the screen description data from 
link server 300 and causes display drive 260 to display 
on the display screen what is intended in the HDML file 
originally received from the network server 
[0045] As mentioned above, in prior art systems, ter- 
minal devices typically run a local browser such as the 
one available from Netscape or Microsoft to interact with 
the Internet. The present invention, however, uses an 
interface engine in a terminal device and a control en- 
gine in a proxy server. In other words, the present in- 
vention uses an Interface engine demanding little com- 
puting resources in a wireless mobile device and a con- 
trol engine utilizing sufficient computing resources res- 
ident in a sen/er device to allow the mobile device to 
effectively interact with a network server. Further, work- 
ing in conjunction with the control engine in the link serv- 
er, the interface engine in the mobile device does not 
require a large amount of computing power or memory 
to cache, parse, process and display a markup lan- 
guage file. 

[0046] To facilitate further description of the present 
invention, Figure 6 illustrates an overview of a system- 
atic configuration according to the present invention and 
should be understood in conjunction with Figure 3. Fig- 
ure 6 shows that a mobile device 602 communicates 
with a network server 604 via link server device 606. 
Network server 604, or sometimes called sen/ice server, 
may be any server on the Internet that provides acces- 
sible hypermedia information. Mobile device 602 and 
link server 606 may correspond respectively to mobile 
device 350 and link server 300 in Figure 3. Service serv- 
er 604 having an I P address, for example, http://www. 
abcnews com provides hypermedia information to net- 
work 608 so that any computing devices coupled to net- 
work 608 can access the information In sen/Ice server 
604. 

[0047] According to one emlxxdiment, the Information 
in network server 604 is a World Wide Web page that 
may be authored in HDML and fetched over network 608 
operating HTTP. From the perspective of mobile device 
602 that ultimately receives the information, link server 
606 receives the HDML files that are then processed by 
message processor 610 and converted to screen de- 
scription data compatible with the device characteristics 
of mobile device 602. The device characteristics may 
include the type and size of display screen and other 
information passed over link server 606 when a commu- 
nication session is established between mobile device 
602 and link server 606. Generally, a request to estab- 
lish the communk;atlon session can be initiated by either 
mobile device 602 or link server 606. During the process 
of exchanging authentication Information, the data rep- 
resenting the device characteristics of mobile device 



602 is received and maintained in link server 606 such 
that the screen description data is generated per in ac- 
cordance with the device characteristics of mobile de- 
vice 602- The detailed description of Initiating the re- 
quest and the processing of exchanging information so 
as to subsequently establish a secure and authenticated 
communication session is described in commonly as- 
signed U.S. Patent Application No. 08/966,988 entitled 
"Method and System for Secure Lightweight Transac- 
tions in Wireless Data Networks" by Hanqing Llao et al, 
which Is hereby incorporated by reference in its entirety. 
[0048] With the established communication session, 
the screen description data are then forwarded to mobile 
device 602 over wireless network 614 operating a wire- 
less communication protocol. Upon receiving and ren- 
dering the screen description data, interface engine 61 6 
causes display screen 618 to display the information 
embedded in the screen description data. 
[0049] Figures 7 A through 7G show the processes of 
navigation requests by mobile device 602 of Figure 6 
and fetching requested information from service server 
604 and forwarding the information subsequently from 
link server 606 to mobile device 602. 
[0050] Prior to describing Figures 7A through 7G, 
some of the features in HDML are discussed. Similar to 
HTML. HDML Is a tag-based document markup lan- 
guage which includes a set of commands or statements 
specified In a card that defines how information is dis- 
played on a small screen Normally a number of cards 
are grouped intoa deck that is the smallest unit of HDML 
information that can be exchanged between network 
server 604 and link server 606 over landnet 608. The 
HDML specification entitled "HDML 2.0 Language Ref- 
erence" Is enclosed and incorporated herein by teier- 
3S ence In its entirety. 

[0051] According to one embodiment of the HDML, 
there are four typical types of cards: a display card, a 
choice card, an entry card, and a no-display card. A dis- 
play card gives information to be displayed to the user. 
-^0 The displayed content can Include any one of, or any 
combination of text, image, and soft keys. A choice card 
displays a list of choices to the user The choices are 
presented in a fonmat specified on the choice card and 
are generally numbered sequentially. As explained 
't^ above, the user selects a choice by depressing a corre- 
sponding key. An entry card is used to obtain input data 
from the user. An entry card displays one or more entry 
lines. The entry line, in this embodiment, can be used 
to receive either numeric or text data. A no-display card 
is a hidden card which is not displayed. The no-display 
card is normally used to execute an Intermediate action 
and generally not known to a user. Regardless of its 
type, a card can contain text, soft keys and images. 
[0052] In one aspect and from the perspective of a 
>S browser operating HDML. choice and entry cards pre- 
vent a user from moving to the next card until the re- 
quested information Is received from the user. When the 
user reaches the last card in a deck and hits a corre- 



8 



15 

spending key. a request for a new deck is initiated. The 
deck requested Is determined by either the deck lhat the 
user has completed, or by the choices made by the user. 
When the deck is completed, the choices and/or data 
entered by the user are typically transmitted along with 
the request to a network server for a new deck. When 
a deck containing multiple cards is received and stored 
in a cache memory, the browser fetches the first card In 
the deck, displays the information in the card, and allows 
the user to respond thereto. Depending on the card type, 
the user responds by entering text or choosing an op- 
tion, and then pressing a predetermined key to transact 
the response. 

[0053] Figures 7A through 7G should be understood 
in conjunction with Figure 6 and with reference to Figure 
3. upon establishing a communication session between 
mobile device 602 and server device 604, an initial 
HDML deck HDML transmitted to link server 606 In- 
cludes an introductory display card and a choice card. 
Figure 7 A is an example of introductory screen display 
702 that Is ultimately drawn on a display screen 700 of 
mobile device 602 by interface engine 616. Figure 7A 
and the following figures are not Interpreted directly from 
the HDML decks received, rather are Interpreted from 
corresponding screen description data translated in link 
server 606 according to the HDML decks received 
therein. As described above, if working directly with the 
HDML files, the terminal (I.e., the mobile device) would 
require both considerable memory to cache the HDML 
files, history and activity states and sufficient computing 
power to run a browser to work with the cached HDML 
files. One aspect which differentiates the present inven- 
tion fundamentally from prior art systems is that the con- 
trol engine in the link server is responsible for tasks that 
require extensive computing resources while the Inter- 
face engine in the terminal is only responsible for ren- 
dering the screen description data to cause the display 
screen to display contents and receiving inputs from a 
user. More specifically, the typical functions that the con- 
trol engine in the link server perform include: 

1 . processing requests from the mobile device; 

2. generating a URL request to a network server, 

3. interpreting markup language files; 

4. generating screen description data; 

5. management of data cache; 

6. management of history; 

7. management of variable states In a markup lan- 
guage file; 

8. maintaining push data, (including alerts), elec- 
tronic mails. 

[0054] According to one embodiment, display screen 
700 displays a graphical image. In another embodiment, 
display screen 700 displays only text. Screen display 
702, and other screen displays described more com- 
pletely below, include a horizontal arrow 704, i.e., a mul- 
ti-screen Indicator translated from a multi-card deck in- 
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dicator, to communicate to the user that screen display 
702 Includes another screen display. To view the HDML 
file, a multi-card deck indicator indicates that the current 
deck includes another card. The inclusion of screen in- 

5 dicators, such as horizontal arrow 704, to communicate 
with the user is optional. The functionality of this inven- 
tion is Independent of such screen indicators. 
[0055] Referenced by 706 is a soft key generally as- 
sociated with one of the generic buttons of the keypad 

^0 of the mobile device 602. A soft key can be used to map 
a generic button into a specified button or activated by 
a touch pen or a finger. In this instance, pressing the 
generic button or touching the key directly is equivalent 
to pressing an "OK" button when the soft key OK is dis- 

75 played. In many palm-sized computing devices, the 
number of the keys is generally kept toa minimum so as 
to provide a larger display screen. The larger display 
screen can accommodate more soft keys, which can be 
directly activated using a touch pen. Soft keys thus pro- 

20 vide an efficient means to Interact with display screen 
700. 

[0056] ■ When the user depresses a predetermined key 
(i.e. one of the generic buttons in this case), thus select- 
ing a soft key, a client module in the mobile device 602 

25 interprets the action and sends a request to link server 
606. Upon receiving the request, control engine 609 in 
link server 606 interprets the request which is, In this 
instance, a request to display the next screen display. 
Control engine 609 calls converter 612 to retrieve the 

30 next card from the received HDML deck, preferably, 
cached in a memory in the link server and converts the 
card in HDML to a SDD file that Is subsequently deliv- 
ered to mobile device 602. Upon receiving the SDD file, 
interface engine 616 draws a new screen display as 

35 shown in Figure 7 B, which would be otherwise displayed 
on a desktop computer running a local browser working 
directly with the HDML file. 

[0057] Screen display 708 In Figure 7B shows a list 
of choices (the original HDML card is a choice card). 

40 Besides the list of choices that can be accessed by the 
user in Figure 78 is a downward arrow, which indicates 
that the screen display Includes additional items that are 
not shown In display screen 700. The screen display can 
be larger than the number of lines available In the dis- 

45 play screen 700 and so the user must scroll the screen 
display to view the complete screen. Thus, to view the 
additional items, the user presses the downward arrow 
key corresponding to the downward arrow Indicator 712 
on the display screen 700.ln this embodiment, when the 

50 downward arrow key is pressed, each line of the display 
is rolled up one line. The resulting display has an icon 
with an upward arrow (not shown) if the menu requires 
onlytwo screen displays. II the menu requires more than 
two screen displays, the second screen display of the 

55 menu would have two Icons, one with the upward arrow 
and another with the downward arrow. To scroll between 
the various lines in the second menu, the user uses the 
downward arrow key. and the upward arrow key. If the 



EP 0 987 868 A2 



9 



17 



EP 0 987 868 A2 



18 



user displays the last line of a card, e.g., the last line in 
the second menu, and presses the downward arrow key 
nothing would happen because the downward arrow 
icon, another soft key, will not be present. In this screen 
display, the user must make a choice before a next dis- 
play screen is available. 

[0058] In this embodiment, each of the menu items is 
available on service server 604 or distributed on several 
server computers coupled to network 608. As explained 
more completely betow, each of the menu items in the 
original HTML file is associated with a numeral that cor- 
responds to a resource locator in the card containing the 
menu items. The resource locator includes an address 
of a particular object associated with one of the menu 
items. In general, a resource locator includes a universal 
resource identifier (URI) or universal resource locator 
(URL) and may include appended data. The address 
can be referenced to another card in the deck cached 
in link server 606 or to a remote object on service server 
604. 

[0059] As shown in Figure 7B, the first item in the 
menu 708 is initially indicated by an arrow 710 as a pre- 
chosen item. If the user decides to proceed with thepre- 
chosen item, the soft key 'OK' may be pressed. Alter- 
natively, a numbered key "I", i.e. one of the 10 num- 
bered keys, can be pressed to cause the client module 
in mobile device 602 to send a new request to link server 
606 for a next screen display. This new request, howev- 
er, is not a simple request as the one from Figure 7A. 
This request may include a resource locator to another 
card in the deck cached in link server 606 or a renriote 
object in service server 604, depending on whether the 
original received HDML includes the information re- 
quested by the new request from nrwbile device 602. 
[0060] This new request corresponds to a hyperlink 
in the card that has been converted to the SDD file cur- 
rently being displayed in Figure 7B. The hyperlink may 
include a URL as follows: 

www.xyzinfo.conn/ABCcorp/sales 
where www. xyzinfo.com can be the URLof sen/ice serv- 
er 604 and /sales may be a hyperlink in an object iden- 
tified by /Softcorp in service server 604. More specifi- 
cally, the card in the original HDML file may be ex- 
pressed as follows: 
< HDML version = "2.0'> 
< CHOICE > 

<CE TASK ~ GO DEST=www. abc.com/ 
sales. hdml> ABC Corp. Sales 

<CE TASK = GO D EST- www.xyzinfo.com> 
XYZ Information 

< CE TASK = GO DEST =www.financialinfo. 
com> Financial Info 

< CE TASK = GO DEST = www.personal- 
web.com > Personal Web Site 

</CHOICE> 

</HDML> 

In the present example, each of the items in the menu 
displayed in Figure 78 corresponds to a URL in the fol- 



lowing, identifying a network server in the Internet: 
www.abc.conn/sales.hdml 
www.xy2inf0.com 
wvvw.financialinfo.com 
www. person a Iweb . com 
When one item is subsequently chosen, the control en- 
gine will generate a URL request to the identified net- 
work server to retrieve the desired information. 
[0061] Afthough converter 612 in link server 606 con - 
0 verts the above code to a SDD file, a much more com- 
pact format for transmitting over wireless network 614. 
A long address, like http://www.xyzinfo.com/Local- 
News/Towns. typically cannot be compressed further. It 
is neither efficient nor wise to use the wireless network 
5 to communicate a nunriber of long addresses in a file 
and return a URL request containing one or more of the 
addresses. Hence the present invention uses one or 
more address identifiers that are communicated over 
the wireless network. Each of the address identifiers 
0 identifies the full address. An address table is main- 
tained in link server 606 that maps the address identifi- 
ers to the actual (full) addresses. The address identify- 
ing or address mapping methods described here are 
significantly different from prior art systems which send 
> terminal device addresses to all hyperlinks in a markup 
language document along with the document to a ter- 
minal device. 

[0062] Figures 8 A and SB show, respectively, two im- 
plementations of address mapping and should be un- 

30 derstood in conjunction with Figure 3 and Figure 6. Ad- 
dress mapping table 800 is identified by a user ID 802, 
Address mapping table BOO includes address identifier 
column 804 and addresses into address buff er806. Ad- 
dress mapping table 800 in Figure 8A is typically estab- 

35 lished when a communication session between a mobile 
device and a link server is created. Each mobile device 
is allocated one address mapping table, which can be 
managed by the account manager in the link server. In 
other words, user ID 802 (e.g., a device IDora subscrib- 

^0 er ID) uniquely associates a mobile device to address 
mapping table 800. During the communication session, 
only the entries in address identifier column 804 are ac- 
tually sent. For example, rather than sending over the 
entire resource locator 

*5 http://www.xyzinfo.com/LocalNews/Towns, address 
identifier "1234' is embedded in a SDD file that is deliv- 
ered to the nrrabile device. Generally mapping table 800 
in Figure 8 A vanishes when the session expires or ter- 
minated. 

[0063] According to another embodiment, the ac- 
count nnanager manages an address mapping table 800 
shown in Figure BB, in which user ID column 802 in- 
cludes identifications (e.g. device ID or subscriber ID) 
of all active mobile devices communicating with the link 
5 server. Address identifiers 804 includes all address 
identifiers corresponding to the actual addresses in ad- 
dress buffer 806 Thus, whenever a nrxjbile device refers 
by using an address identifier to a resource locator, the 
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actua) address is retrieved from address buffer 806 us- 
ing the address identifier and used in a URL request 
generated by the control engine to the identified network 
server. 

[0064] According to another embodiment in which the 
SDD is a group of Imp data, the actual addresses are 
mapped to their relative positions in a final screen dis- 
play. For example, the above four URLs are hyperlinks, 
according to the original HDML file, to be displayed one 
in each of successive lines. Thus their relative positions, 
linel, Iine2, Iine3 and Iine4, each corresponds to one of 
the URLs. The relationships between the relative posi- 
tions and the actual URLs may be maintained in the ad- 
dress table discussed above or directly by the control 
engine. If a user eventually chooses one of the hyper- 
links, a (client) request from the mobile device will com- 
prise include the chosen position. The request may be 
expressed as follows: 

client request = (SeqID, link, topline); 
where "SeqID" ensures that the client request Is syn- 
chronized with the Imp data fetched for the mobile de- 
vice, from which the client request is produced, "link" is 
one of the parameters that indicates which link (URL) is 
chosen and lopline" is the position in the screen display 
from the Imp data. For example: client request = {64, 2, 
0}; Upon receiving the client request, the control engine 
processes the request and produces an updated re- 
quest including the actual URL corresponding to the 
chosen position, for example {■http://www.xyzinfo. 
com"}, which causes a connection to the service server 
identified by the URL. 

[0065] Returning to Figure 7B, the user may scroll the 
choice arrow 710 downward if the pre-chosen item Is 
not a desired one. It should be noted that scrolling to a 
selected Item is a feature that is specific to this example, 
and in general is not required to implement the Inven- 
tion. Other methods can be used to indicate the user's 
choice on display screen 700 such as a horizontal high- 
lighting strip overshadowing the choice, If such an indi- 
cation is desired. As described above, the user may sim- 
ply key in one or more numerals to select an item that 
Is of interest. 

[0066] As described above, screen display 71 6 also 
includes the representations of two soft keys, an OK key 
706, and a Back key 714. In this example, these soft 
keys are defined only for the card used to generate 
screen display 716. The "OK" key allows the user to pro- 
ceed with the chosen item and the "Back" soft key allows 
the user to go back the previous screen display if so de- 
sired. In the present Invention, the "Back" soft key may 
generate a request that is sent over to the link server 
from which the previous screen display is fetched again. 
Other keys can be implemented. For example a 'Home" 
key, resulting in a request that returns the user to screen 
display 708 of Figure 7B. The "Home" key may be as- 
sociated with a resource locator identifying the card rep- 
resenting screen display 708. Specifically, the link serv- 
er manages a limited history stack of recent requests 
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made by the mobile device in a memory. When a request 
is made, the control engine looks up the history stack to 
see if the request is an "old" one. For example, when 
the "Home" key is pressed, the request can be found in 
5 the history stack and the contents, either in the form of 
an HDML card or an SDD file, can be retrieved from 
memory and forwarded to the mobile device for display. 
[0067] As shown in Figure 4C, the user moves arrow 
710 downward to the second item. Display screen 716 
10 shows four menu items numbered consecutively. As de- 
scribed above, the downward arrow indicates that there 
are more items in the next screen. Each of the items has 
an address identifier For example, for the first four 
items, the respective address identifiers may be: 

i2ab 

231a 

abc3 

1629 

each address identifierxorrespond to an address stored 

20 in the address buffer of link server 606: 
www.abc.com 
www.xyzlnfo. com 
www.financialinfo.com 
www.personalweb.com 

25 When the second Item (i.e., 231a) is chosen, www.xyz- 
info.com is Intended. After a predetermined button is 
pressed (e.g., the soft key OK or the numbered button 
"2") is pressed, a request Including the address identifier 
for the selection is transmitted to link server device 606 

30 by the client module in mobile device 602 over network 
614. Alternatively with regard to the specific Imp data 
implementation, the request includes the selection in 
terms of the relative position in a display screen as de- 
scribed above. In response to the selection, control en- 

35 gine 609 processes this request and formulates a new 
or updated request containing the actual URL Identified 
in the client request^ which causes a connection to serv- 
ice server 604. Through the server module, the link sev- 
er receives another HDML deck file from service server 

40 604. Upon receiving the new HDML deck, message 
processor 610 processes the deck for the desired card 
and sends a corresponding SDD file derived from the 
desired card to mobile device 602. 
[0068] In Figure 7D, there is shown a new screen dis- 
play 718. Typically, it Is based on one of the cards in a 
new deck received in the link server as a result of the 
request from screen display 716. The deck is cached in 
the link server and the first choice card is converted to 
a SDD file that is rendered by the interface engine in the 

so mobile device for display. If the user proceeds with any 
of the items, for example, "Local News', a request is 
made from the interface engine in the mobile device and 
received by the corresponding control engine in the link 
server. The control engine causes the message proces- 

55 sor to retrieve a card identified by the request from the 
cache and convert the card to a SDD file and forwards 
the file to the mobile device for display. 
[0069] Figure 7E shows a display screen 718 result- 
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ing from the "Local News" request. Display screen 718 
asks the user for specific date information so that the 
news corresponding to the specified date can be pro- 
vided The original HDML card that corresponds to dis- 
play screen 718 is an entry card that requires an input 
from the user. Hence the corresponding SDD file con- 
verted from the HDML entry card requires the input at 
cursor 720. Figure 7F shows that the input 722, i.e. date 
information, is typed in. Upon pressing soft key "OK" 
706, the interface engine sends a request including the 
input data over to the control engine that performs var- 
iable substitutions. Variable substitutions, permitting 
sharing of data between cached cards, substitute the 
variable in the original HDML card with the actual infor- 
mation. As a result, an updated HDML card is locally 
and dynamically generated and then converted to a new 
SDD file that is returned to the interface engine for dis- 
play. Figure 7G shows a screen display 724 with the 
substituted data information. In this example, the updat- 
ed HDML card is another entry card, hence screen dis- 
play 724 asks for further information in order to deliver 
accurate infomnation to the user. If the user supplies the 
"town" information being requested and presses the 
"OK" soft key. a request is made and sent to the link 
server in which the supplied information is used to sub- 
stitute a corresponding variable and an updated request 
with the date and town information is generated. Typi- 
cally, the updated request is sent to the network server 
supplying the information, but the updated request may 
be filled locally in the link server if the original HDML 
deck is large enough to include the desired information. 
Further detailed description of the management and 
processing of the variables in a markup language file is 
provided in commonly assigned U.S. Patent Application 
No. 09/071,235 entitled " Method for Inline Variables 
Management in a Hypermedia Display Language" by 
Peter F. King et al, which is hereby incorporated by ref- 
erence in its entirety. 

[0070] Figures 9A to 9G together constitute a process 
flow diagram showing the process performed by a link 
server device and a mobile device according to one em- 
bodiment of the present invention and should be under- 
stood in conjunction with Figures 3A to 3B and Figure 
6. At 904, link sen/er device exchanges information with 
the mobile device to establish a communication session. 
The request to establish a communication session is in- 
itiated from the link server by sending a message to the 
targeted mobile device. The message includes a device 
identification of the mobile device. Upon receiving the 
message, the mobile device starts exchanging informa- 
tion with the link server. The exchanged information may 
establish the encryption keys and the encryption 
scheme to be used for the session. In addition, the mo- 
bile device delivers to the link sever a set of device char- 
acteristics information regarding the type and size of the 
display screen of the mobile device. At 906, the account 
manager in the link server associates the device infor- 
mation with the session just established Typically the 



device information is cached in a memory along with 
other information about the mobile device. If the mobile 
device is an authorized device, there is a corresponding 
account that was established when the mobile device is 
activated. If the mobile device contacts the link server 
the first time, an account is established by the account 
manager. Therefore, the device characteristics informa- 
tion is always associated with the account of the mobile 
device. 

[0071] At 908, the account manager assigns a control 
engine to work in conjunction with the interface engine 
in the mobile device. At 910, the account manager de- 
tects, through the server module, any message arrived. 
At 912, the source of the message is identified (i.e., 
whether the message is received from a network server 
or from the mobile device). 

[0072] At 914, when the received message is from the 
network server, the control engine along with other mod- 
ules in the link server-determines the message type. In 
this embodiment, there are broadly two message types 
that are processed distinctively from the prior art sys- 
tems. Specifically, these message types are notifica- 
tions and markup language (ML) files. The notification 
or alert message indicates the arrival of an electronic 
mail or fulfilment of certain requests (e.g. , sale of a stock 
at a limit price). The notification or alert message in- 
cludes a device identification identifying the mobile de- 
vice, an alert type (instructing the mobile devrce to beep, 
vibrate or display a visual sign), an alert title (a text string 
describing the subject matter of the alert), a life-time 
specifying a time period during which the alert should 
be delivered) and a URL that a user can request when 
the user desires to respond to the alert. Alternatively, an 
alert can be expressed as follows: 
Notificationalert = {023. "new mail", 4, www. wireless. 
conrVmaiLretrieval/87473} where "023" is a special 
code that can causes the mobile device to beep, the title 
'new mail" is then displayed on the screen of the nrobiie 
device, the value "4" specifies that the notification mes- 
sage be delivered within four hours or discarded, and 
the last entry in the notification is the URL to retrieve the 
new noail identified by "87473" from a mail server iden- 
tified by www.wireless.com. 

[0073] As indicated above, a notification or alert mes- 
sage is not always immediately deliverable; sometimes 
the mobile device is out of the service area or the mobile 
device is turned off. Consequently, the account manager 
of the link sender maintains'a notificatbn list or an alert 
list for each mobile device. Upon receiving a new alert 
message, at 91 6. the account manager determines from 
an alert list if the newly arrived alert message corre- 
sponds to a URL already on the alert list. If there is an 
identical URL in the alert list, at 920, the corresponding 
entry in the alert list is updated with the newly arrived 
alert message. If no identical URL is found, at 922 the 
newly arrived alert message is inserted. The newly ar- 
rived alert messages are sequenced in the alert list for 
delivery to the target nrK)biIe device. 



23 



EP 0 987 868 A2 



24 



[0074] At 924, the alert message is modified by sub- 
stituting the actual URL by using an address identifier 
retrieved from an address table. At 926, the modified 
alert message is sent to the mobile device over the wire- 
less network. It should be pointed out that the above 
alert list update is not necessary if the newly arrived alert 
message is immediately delivered. Further it- should be 
pointed out that the alert list may not be necessarily 
maintained in the link server device and, as will be ex- 
plained below, may be maintained in the mobile device. 
[0075] Returning to 914, the situation when the re- 
ceived message from the network is a markup language 
(ML) files is described. At 938, the message processor 
in the link server processes the ML files. The processes 
at 938 may include caching the ML files in proper mem- 
ory, parsing the ML files to generate internal data struc- 
ture needed to generate SDD files. In particular, at 940 
and 942 all the URLs in the received ML files are sub- 
stituted with corresponding address identifiers, with the 
actual URLs are stored In the address table maintained 
in the link server or the relative positions of the URLs 
are determined with regard to the Imp data implemen- 
tation. At 944. the message processor converts the 
processed ML files to SDD files based on the mobile 
device's characteristics information, to allow proper dis- 
play of the SDD files in the mobile device. To ensure that 
the control engine in the link server is in synchrony with 
the interface engine in the mobile device, at 946, the 
SDD files are respectively sequenced, preferably num- 
bered consecutively and, at 948. delivered to the mobile 
device over the wireless network. 
[0076] Returning to 912, the situation when the mes- 
sage is from a mobile device is described. Typically, 
such a message includes one or more (client) URL re- 
quests. At 960, the control engine processes the mes- 
sage after the account manager verifies that such re- 
quests are permissible at 958. Depending on the serv- 
ices subscribed, each mobile device serviced by the link 
server may have the different privileges from other mo- 
bile devices to the services offered by the link sen/er. If 
a request is granted at 958, the link server processes 
the request. Collective fy, a (client) request may be ex- 
pressed as follows: 

client request = {SeqID, Event. Choice, Link, AlterlD, 
Topllne, Entry, URL} where "SeqID" ensures that the cli- 
ent request is synchronized with a SDD fetched to the 
mobile device, from which the client request is pro- 
duced. "Event" indicates what kind of request this client 
request is, for example, Softkey meaning a soft key ac- 
tivation, AlertSelect meaning that an alert has been re- 
sponded to fetch a message in reference to the alert, 
and 'Accept', 'GotoURL" and "DeleteSelecf, to name 
a few. "Choice" indicates which choice in a screen dis- 
play has been chosen, "link" is one of the parameters 
that indicates which link (URL) is chosen. "AlterlD" com- 
prises one or more those address identifiers, 'topline" 
is the position in the screen display from the SDD and 
"Entry" typically holds inputs entered by a user and 



"URL", as the name suggests, holds an address enter 
by the user. 

[0077] At 960, the request is examined. In some in- 
stances, at 962, variables in the requests are substituted 

5 to provide an updated request, as explained below. 
[0078] According to one aspect of the invention, var- 
iables are used to hold user Input data. Such user input 
data can be collected, for example, in response to a que- 
ry provided to the user in a display screen. When the 

10 user input data (e.g., a number) is entered by the user, 
the user data received Is provided on the next display 
screen to provide feed back to the user Specifically, the 
link server receives an ML file in which are defined a 
number of variables. The variables In the ML file consti- 

15 tute information to be requested at a terminal device. 
The ML is converted to a corresponding SDD file to be 
displayed on the mobile device, and in response to the 
display screen, the user enters the required input data 
and a request is dispatched containing the input data to 

20 the link server, after a predefined key is pressed. In prior 
art systems, a terminal device running a browser per- 
forms the substitutions locally. In the present invention, 
the mobile device operates only an interface engine 
without the capability of performing the substitution. The 

25 substitutions are Instead performed by the control en- 
gine in the link server when the request from the nrobite 
device Is received at 964. The link server responds to 
the request by sending the mobile device a new SDD 
file that Includes the user data substituted for the varia- 

30 bles at 966. 

[0079] According to another aspect of the present in- 
vention, some values received from the mobile device 
for variables in the ML files are in the form of address 
identifiers that must be substituted with the actual URLs. 

3S Examples of a request Including address identifiers in- 
clude a new information request to a network server or 
a request to retrieve email. Upon receiving such a re- 
quest, the actual URLs are retrieved by the account 
manager from an address table In the link server At 968, 

40 the original requests from the mobile device are modi- 
fied to produce updated requests with the actual URLs 
substituted and the updated requests are then sent to 
the identified network server(s) corresponding to the 
URLs at 970. 

45 [0080] Figures 9E to 9G constitute a process flow di- 
agram of the operations executed in the mobile device, 
which corresponds to the processes in the link server. 
At 953, the mobile device exchanges information with 
the link device to establish a communication session. 

50 The request to establish a communication session can 
also be initiated from the mobile device by sending a 
message to the link server. Besides a device identifica- 
tion of the mobile device, the message includes a URL 
of the link server. To establish the communication ses- 

55 sion, device characteristics information is provided to 
the link server. Such characteristics information may in- 
clude the size and type of the display screen of the mo- 
bile device, for example. After the communication ses- 
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sion is established, the interface engine works at 957 
with the control engine in the link server 
[0081] At 959. the client module in the mobile device 
receives a nnessage. Typically the nnobile device re- 
ceives three kinds of messages: notifications. SDD files 
and local service requests. At 963. a notification mes- 
sage arrives. Note that a notification message received 
at the mobile device Is different from the notification or 
alert message provided by a network server. The notifi- 
cation message received at the mobile device Is a dis- 
tilled version with no explicit URLs. Upon receiving the 
notification message, the client module accesses an 
alert list in the mobile device to determine If there is an 
Identical notification pending there at 965. Sometimes 
a user of the mobile device may not necessarily or im- 
mediately respond to an alert, the mobile device hence 
maintains an alert list to keep record all the received no- 
tification or alerts. If a pending notification identical to 
the newly received notification message is found, the 
alert list gels updated with the newly arrived notification 
message at 967. Otherwise, I.e., no identical notification 
message is found In the alert list, the newly arrived no- 
tification message is added sequentially Into the alert 
list at 969. Meanwhile, the user is notified in accordance 
with the alert type In the received notification message 
at 971 . When the user decides to respond to the notifi- 
cation and presses a key or activates a soft key, a re- 
quest corresponding to the notification message is sent 
to the link server at 973. 

[0082] At 975, a message is received requesting an 
update to the local services in the mobile device. Local 
services may include functions for modifying wireless 
voice/date protocols, configuration or system parame- 
ters, bookmarks, addresses, subscriber provisioning In- 
formation and other parameters that may enable or dis- 
able certain telephony and data-features of the moblle 
devices. Technically, the interface engine recognizes 
such a message by a special prefix indicating the "local 
service" request. According to one embodiment, a URL 
for a local service always begins with 'device:', (e.g., 
devlce;addressbook). 

[0083] Upon the arrival of a local service request, the 
local service in the mobile device is Invoked. For exam- 
ple, a user may navigate to a page providing email serv- 
ice to the mobile device. After a key Is pressed or a soft 
key is activated, a request is sent to the control engine 
of a link server, which in turn responds by a local service 
request which causes an address book to be displayed 
In the mobile device. After the user makes a selection 
from the address book, at 977, the mobile device sends 
another request specifying the selected address to the 
control engine which then sends the mobile device an 
SSDflle. Upon receiving the SSD file, the display screen 
displays a page which allows the user to proceed with 
composition of a mall message. 

[0084] At 981 , the situation when the received mes- 
sage Is an SDD file is described. Upon receiving the 
SDD file, the interface engine renders the SDD file and 



causes the display screen of the mobile device to dis- 
play text or graphics according to the SDD file at 983. 
Within the display screen, the user may browse the 
screen display at 985 by pressing a navigation key to 
5 reposition a cursor to a subject of interest. For further 
information on the selected subject, the user may press 
a predefined key; hence a URL request Is generated at 
987. Also at 985, the user may be asked for input data 
to some context. Once the input data is entered, the user 
10 may press a predefined key, such as the "OK" key to 
generate a URL request at 987. The URL request is then 
sent to the link server for processing at 989. 
[0085] The present invention is described above by 
way of example using specific embodiments. Numerous 
IS changes and modifications can be made within the 
scope of the invention claimed below. 

Claims 

20 

1. A method for an interactive two-way communication 
mobile device having a display screen and commu- 
nicating with a wireless network to Interact with a 
network server, the method comprlsing:- 

2S 

initiating a control engine in a link server device 
of a landnet after the mobile device establishes 
a communication session with the link server 
device over the wireless network, wherein the 
link server device comprises an account man- 
ager configured to manage a user account of 
the mobile device; and a message processor 
configured to receive a message from the net- 
work server over the landnet; 
35 associating the control engine with an interface 

engine operating in the mobile device corre- 
sponding to the user account; and 
operating the message processor to convert 
the message to a compact data file that can be 
efficiently transported In the wireless network. 

2. A method as recited in claim 1 further comprising 
forwarding device characteristics infomiation of the 
display screen from the mobile device to the link 
server device over the wireless network. 

3. A method as recited In claim 2 wherein the compact 
data file is screen description data that can be di- 
rectly rendered by the interface engine in the nrwbile 

50 device. 

4. A method as recited in any preceding claim wherein 
the message received from the network server Is a 
notification comprising a device Identifier identifying 

55 the mobile device and a universal resource Identifi- 
er 

5. A method as recited in claim 4 wherein said con- 



14 



27 



EP 0 987 868 A2 



28 



verting the message to a compact data file by the 
message processor comprises:- 

looking up in a notification list managed by the 
account manager for an entry substantially 5 
equivalent to the received notification in the link 
server device; 

updating the notification list with the received 
notification; 

substituting the universal resource identifier io 
with an address identifier; 
storing the universal resource identifier and the 
corresponding address identifier in an address 
table managed by the account manager in the 
link server device; and i5 
converting the notification with the universal re- 
source identifier substituted by the address 
identifier to the compact data file. 



6. A method for an interactive two-way communication 20 
mobile device of a wireless data network to interact 
with a network server, the mobile device having a 
display screen to interact with a network server, the 
method comprising: - 

25 

establishing a communication session between 
the mobile device and a link server device over 
the wireless network, the link server device be- 
ing coupled to the network server through a 
landnet so that the mobile device interacts with 30 
the network server via the link server device; 
associating an interface engine operating in the 
mobile device with a control engine operating 
in the link server device with an account estab- 
lished for the mobile device in the link server 55 
device; 

receiving a compact data file generated in the 
link server device over the wireless network; 
and 

rendering the compact data file by the interface ^0 
engine to display contents of the compact data 
file on the display screen of the mobile device. 

7. A method as recited in claim 6 wherein said estab- 
lishing a communication session comprises for- ^5 
warding devce characteristics information of the 
display screen of the mobile device to the link server 
device over the wireless network. 

8. A method as recited in claim 6 or 7 where in the com- so 
pact data file is an updated notification processed 

in the link server device from a notification received 
from the network server, the notification comprising 
an alert type and an universal resource identifier. 

ss 

9. A system, coupling a wireless network to a landnet, 
for an interactive two-way communication mobile 
device having a display screen to interact with a net- 



work server, wherein the mobile device is coupled 
to the wireless network and the network server is 
coupled to the landnet. the system comprising: - 

a memory for storing code for a server module; 
a data storage device for maintaining a user ac- 
count for the mobile device; 
a processor coupled to the memory and the da- 
ta storage device, the processor executing the 
code in the memory to cause the server module 
to:- 

maintain executing a control engine associated 
with an interface engine executing in the mobile 
device; 

receive a network message from the network 
server over the landnet operating a first com- 
munication protocol; 

buffer the network message in a cache memo- 
ry; . . 

generate a compact message from the network 
message; and 

send the compact message to the mobile de- 
vice over the wireless network operating a sec- 
ond communicatbn protocol. 

10. A system as recited in claim 9 wherein the proces- 
sor executing the code in the memory further caus- 
es the server module to establish an account man- 
ager to manage a user account of the mobile de- 
vice; the account ensuring that the control engine 
operates with the interface engine in concert. 

11. A system as recited in claim 9 or 10 wherein the 
network message is a notification comprising an 
alert type and a universal resource identifier 

12. A system for interactive two-way communications 
with a network server through a link server device, 
the system comprising:- 

a display screen; 
an input interface; 

a memory lor storing code for a client module; 
a processor coupled to the memory and com- 
manding the display screen and the input 
means, the processor executing the code in the 
menrxjry to cause the client module to:- 
execute an interface engine when activating a 
predefined key; 

maintain the interface engine to work with a 
control engine operating in the link server de- 
vice in concert; 

receive a compact message from the link serv- 
er device over a wireless network, wherein the 
compact message is generated by a message 
processor in the link server device with refer- 
ence to a network message received from the 
network server over a landnet; and 
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render the compact message to cause the dis- 
play screen to display contents in the network 
message. 

3. A system. as recited in claim 12 wherein the input s 
interface is a phone keypad. 

4. A system for interactive two-way communications 
with a network server of a landnet operating a land- 
net communication protocol, the system compris- to 
ing:- 

a plurality of interactive two-way communica- 
tion mobile devices, each having:- 

15 

a display screen; 
an input intertace; 

a memory for storing code for a client mod- 
ule; and 

a microcontroller coupled to the memory, 20 
the microcontroller executing the code in 
the memory to cause the client module to 
maintain an interface engine therein; 

a link server device coupling the landnet and a 25 
wireless network operating a wireless commu- 
nication protocol; the link server device com- 
prising; - 

a memory for storing code for a server 30 
module: 

a processor coupled to the memory, the 
processor executing the code in the mem- 
ory to cause the sen/er module to;- 
create a manager managing a plurality of 3S 
user accounts, each with respect to a de- 
vice ID of one of the mobile devices; 
maintain a plurality of control engines, 
each being associated with the interface 
engine in each of the mobile devices after 40 
a communication session is respectively 
established between the link server device 
and the each of the mobile devices over the 
wireless network; 

receive a network message from the net- 45 
work server over the landnet; the network 
message comprising information of the de- 
vice ID of the one of the mobile device; 
generate a compact message from the net- 
work message according to display char- so 
acteristics information of the one of the mo- 
bile devices; and 

send the compact message to the one of 
the mobile devices over the wireless net- 
work. 55 
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Abstract 

Mobile Computing and World Wide Web are rapidly gaining popularity. They are fundamental technologies for 
a vision of information access for anyone, anytime, anywhere. However, mobile information access has to cope with the 
heterogeneity, dynamic and restrictions (e.g., narrow bandwidth, restricted resources) of the mobile environment. In this 
paper we present a system that supports a useful integration of portable computing devices such as (Sub-)Notebook, 
Palmtop or Personal Digital Assistants within the present WWW infrastructure. We propose an architecture for 
a context-aware adaptation within a mobile WWW environment. It enables resource adaptive access to any content 
within the WWW. The main idea is to exploit meta-information about the resource environment and user preferences to 
find a suitable adaptation pipeline to overcome most limitations of mobile information access. We discuss our first 
experiences we made with Ada Web prototype. Then we present the extensions of our adaptation system to improve the 
mobile WWW access. © 1999 Published by Elsevier Science Ltd. All rights reserved. 

Keywords: Mobile computing; World Wide Web; Adaptation; Proxy; PDA 



1. Introduction 

With the development of enabling technologies such as 
wireless networking and various types of affordable mo- 
bile devices, mobile computing has started to be widely 
accepted and applied. With this, the possibilities of mo- 
bile data communication using wireless networks are of 
rising importance. This mobile technology will also be- 
come more and more integrated into the World Wide 
Web in order to be able to access "everywhere" in the 
Web. The combination of mobile technology with 
WWW is one important step towards a global informa- 
tion infrastructure. 

In general, a mobile WWW application requires a mo- 
bile device such as Personal Digital Assistants (PDAs) or 
notebooks to access a remote WWW server. The connec- 
tion to a WWW-server can be established with commu- 
nication facilities provided by a mobile phone or the 
mobile computing device itself (see Fig. 1). This enables 
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mobile users equipped with a portable computer to ac- 
cess information anywhere and anytime. However, these 
kind of applications face new challenges that are mainly 
caused by the hmited resources (e.g., display, battery, 
memory size, processing power) of mobile devices com- 
pared to desktop environments and the low bandwidth of 
wireless narrowband wide-area networks. Due to these 
shortcomings, new concepts are needed to provide effi- 
cient access to WWW servers within a mobile environ- 
ment. Otherwise, WWW applications will be rejected by 
the users. In this context, a'daptation is one of the most 
important concepts, firstly, in overcoming the most seri- 
ous problems and secondly, in providing an efficient 
access to information services within the limits of the 
system. 

Adaptation can be achieved at various levels 
(c.g., network-, system-, application-level) within a 
mobile system and its applications. Several techniques, 
such as pre-fetching, caching, compression, and filtering 
are suitable for this purpose. These techniques can be 
applied to utilise the bandwidth efficiently, reduce com- 
munication overhead, and hide network latency. 

We have developed an adaptation concept at applica- 
tion level applying a rule- based system that utilises the 
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knowledge of the resource environment and user prefer- 
ences to adjust the access of distributed information 
services and presentation within the Hmits of the mobile 
system. In this paper, we will give an overview of our 
work by introducing the system architecture and its main 
components. Then, we will focus on the management of 
resources with regard to mobile WWW access. The re- 
source management encompasses the functionality for 
the maintenance of resource information such as storage, 
retrieval, deletion and update of resource characteristics, 
and to monitor resources. Then, we will introduce the 
trader component as a component that helps to keep the 
latency of the adaptation service low and we will also 
discuss the introduction of client components to enhance 
the adaptation process (data compression, location 
tracking). 



2. Adaptation concepts for a mobile WWW access 

Looking at present the WWW technology with regard 
to its apphcability for a dynamic content adaptation, we 
can identify the folJowing aspects: 

• Common approaches providing dynamic adaptation 
of WWW content are techniques using cookies, URL 
extensions or CGI scripts. However, these solutions do 
not support the specification and exploitation of user 
preferences or resource profiles for a context-aware 
adaptation. 

• The current version of HTML offers some tags and 
attributes Hke ALT to enable the presentation of an 
alternative content. However, HTML is not designed 
for the definition of different layouts for various screen 
resolutions. 

• When using Java or JavaScript for the adaptation, the 
creation of HTML pages would be extremely expen- 
sive due to. the necessity of specific knowledge of the 
developer. Furthermore, the original WWW content 



would be transferred to the client and the adaptation 
would use the resources on the client side and require 
Java/JavaScript support. 

To summarise, all approaches mentioned above do not 
provide sufficient functionality for a dynamic adaptation. 
Therefore, several proposals address the theme of mobile 
WWW access by using an application-level approach. In 
general, they adjust the WWW content presentation to 
the Hmits of the specific mobile device and the mobile 
connection. One possible model is the adaptation of 
WWW content on the client side. This is often used by 
WWW browser developers. However, due to the re- 
stricted memory and the low processing power, a mobile 
client (e.g., a PDA) will not allow expensive computing 
adaptation operations. Moreover, if it is not possible to 
present the WWW content on the client device and it is 
therefore filtered out, then the data has been transferred 
unnecessarily. 

A further approach is to use machines within the fixed 
network, that pre-process or filter the WWW content for 
the mobile device facilities. This can be done on the 
server itself or on an intermediate site, a so-called proxy 
between chent and server. Using a proxy for the WWW 
access is a common approach [1-3]. However, the 
current solutions are not generic in terms of hardware 
profiles and user preferences. Therefore, we propose a dy- 
namic WWW content adaptation system that evaluates 
user preferences and available resources to identify the 
most suitable adaptation strategy for the current context 



3. Related work 

At present, mobile WWW access is being discussed by 
the W3-consortium- The Mobile Access Interest Group 
is endeavouring to create a proposal for a new WWW 
standard which supports resource-limited devices 
(e.g., mobile phone with text display only). Two propo- 
sals exist: 
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• Compact HTML [4] is a subset of different HTML 
standards. The selected tags and attributes are related 
to resource constraints of mobile clients. 

• Wireless Mark-up Language (WML) [5] is the pen- 
dant to HTML. It is based on the Extended Markup 
Language (XML) and has been designed by the WAP- 
Group (Wireless Application Protocol). 

These are activities that introduce new languages and 
proprietary protocols to improve the mobile WWW ac- 
cess. A widespread example is the popular TopGun 
WingMan for the Palm -computing platform [6]. There 
a split-browser is used: HTML parsing and conversion 
into a proprietary format is done on the proxy, display- 
ing of this format is done by the browser. As already 
mentioned above, another approach is the use of proxies 
to adapt the access of information services. Within the 
WWW infrastructure various proxy configurations are 
possible. A proxy can be located on the client, on an 
intermediate site or even on the server itself. In general, 
one can distinguish between single- and dual-proxy 
architectures supporting mobile WWW applications [7]. 

Tele Web [8] is one example for a single-proxy archi- 
tecture, where the proxy is located on the client. It caches 
documents and enables an asynchronous email style 
browsing that can be controlled by the user. Bui, this 
solution uses additional resources of the mobile comput- 
ing device. 

A number of applications use a dual-proxy architec- 
ture running a proxy on the client as well as in the fixed 
network. Then, additional resources of hosts located in 
the fixed network are used to pre-process the requested 
data for the mobile client. These tasks are performed on 
specific stationary servers that can co-operate with the 
proxies on the mobile clients. In other words, the appHca- 
tion is spht into two parts, where one part of the applica- 
tion complexity is moved to the fixed network. Typical 
examples for this category are Mowgli [9] and MobiS- 
cape [10], They make use of a proxy on a mobile client 
and on a stationary server applying a cache on both 
sides. The WIT- project [11] uses proxies to split an 
application between client and server. However, they 
all need additional resources or functionality on the 
client side. 

TranSend [12] and Digestor [13] are single-proxy 
architectures where the proxy is located in the fixed 
network. Digestor has an intelligent proxy that trans- 
forms Web-pages according to design heuristics. In order 
to reduce the bandwidth requirements, TranSend applies 
an infrastructure proxy service to provide datatype- 
specific distillation (i.e., quality reduction on images). 
Both systems need only standard Web browsers and 
move the computational complexity of the WWW access 
partly to the proxy within the fixed network. 

All of these .proposals provide solutions to enhance 
mobile WWW access, but they do not address dynamic 



adaptation of WWW content on different mobile clients. 
Furthermore, they do not answer the question of how 
already existing WWW content can be adapted for pre- 
sentation on resource- limited mobile computing devices. 

4. Ada Web 

The before-mentioned approaches have shown that 
a proxy approach offers the most advantages and should 
be preferred to the server or chent approach. However, 
the above-listed proxy approaches are dedicated to only 
one or two special mobile devices and do not support 
a broad spectrum of mobile devices. Therefore, we have 
designed an adaptation service, that is placed on a proxy 
between client and server, and can adapt the WWW 
content, which a mobile user is able to access fronn the 
network, to the current context of the user. This context 
includes the mobile device, the user's preferences and the 
current available bandwidth of data transfer between the 
mobile device and the proxy. The concept of Ada Web is 
shown in Fig^ 2. 

In order to carry out the adaptation, we are building 
a collection of adaptation rules. The rules define the 
transformation or modification of WWW content de- 
pending on the context parameters. These parameters 
have an influence on the premise of a rule, which is 
defined by a Boolean expression. When the premise is 
evaluated and the condition is fulfilled the actions of 
a rule are executed. An action correlates to one internal 
or external program that is responsible for a certain 
adaptation process. In the following paragraphs these 
kind of programs will be caWcd filters. 

The concept and architecture of Ada Web has already 
been introduced in [14], but, in the meantime, the con- 
cept and the architecture have been extended for the 
integration of new components. In our previous concept, 
the adaptation was the only optimization of the WWW 
access and the whole adaptation process was localised on 
the proxy. The advantage of this is that no client com- 
ponent has to be developed for a mobile client. The 
development of a cUent comp>onent (e.g., browser, mess- 
age handler) for a broad spectrum of mobile devices is no 
trivial task and is associated with high costs due to the 
different operating systems, the different programming 




Fig. 2. Proxy-based content adaptation. 
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Fig. 3. Context-dependent adaptation pipeline with filter selection. 



models and different developer tools. On the other side, 
content adaptation was the only technique that was 
supported by Ada Web though there are a lot of other 
possibilities to make the mobile WWW access more 
efficient. To integrate approaches like a Level of Detail 
model for image transmission presented in [15J and 
a message handler according to this model using data 
compression and caching strategies [16], we have ex- 
tended the concept and can also support a client-side 
component. 

Another modification of our system relates to the re- 
garded resources. In contrast to our previous approach, 
where the idea of a resource was identical to the idea of 
the mobile device, filters are managed as resources. In- 
stead of calling up a filler directly within the action part 
of a rule, the name of the operation appears in this place. 
The name of the operation is a key to a hst of filters which 
perform this operation (see Fig. 3). From this list thfc most 
appropriate filter is chosen, in general, the filter with the 
least workload. 



4. J. Base system of AdaWeb 

Fig. 4 shows the main components of the AdaWeb 
system. The highlighted components symbohse the 
extensions to the previous approach and are responsible 
for the realisation of the new concepts mentioned at the 
beginning of Section 4. In this section we will give a 
description of the components of the base system and 
discuss our first exf>eriences. 

Implemented components of AdaWeb which build the 
system according to the base system are: 



• Resource information base (RIB) contains all informa- 
tion needed by AdaWeb, both from and about the 
outside world, and is therefore the central information 
mterchange and storage management component of 
AdaWeb. It is used for user and session management 
and serves the role of interprocess communication. 

• User registration is responsible for the administration 
of user accounts and user profiles. Device and user 
profiles are indicated by one key, which is transmitted 
to the user device as the result of the registration 
process. 

• Request manager identifies the context of the web-client 
by analyzing cookie information or stripping special 
URL-prefixes. It then hands the request over to a nor- 
mal caching proxy for retrieving the requested data 
from the foreign host. In the mean time it triggers the 
RIB to pre-load the data which defines the web-client 
context. 

• Adaptation component loads the user and device in- 
formation from the RIB and evaluates the premises of 
the adaptation rules. For evei^ valid premise the op- 
erations of the corresponding action part are executed. 

More detailed information about the listed parts of the 
system are given in [14]. These components represent the 
first prototype of AdaWeb which was used to evaluate 
our adaptation concept. Analyzing Web statistics with 
regard to the transferred volume of data has shown that 
images have a dominant percentage (73.5%) in contrast 
to HTML documents (23.5%). Fillers for image opera- 
tions like scaling and color reduction as well as format 
conversion are widely available, for example GIMP [1 7]. 
The definition of rules for the control of these filters 
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Fig. 4. Architecture of Ada Web. 



depending on display size and color depth of the mobile 
device or the network capabihly is not complex. There- 
forCj the introduction of image adaptation processes 
within our system is relatively simple and then by using 
AdaWeb transfer time could be significantly reduced 
by 60%. 

The difficulties arise when trying to adapt HTML 
documents, because semantic information is required 
about the content as well as the layout. Semantic in- 
formation is useful to subdivide large text pages into 
smaller sections. Layout information is required to scale 
the components of a multi media document. To extract 
this information which is solely based on the document is 
very difficult. On one hand. HTML tags that could code 
the structure of a document are used for designing the 
text style, on the other hand, layout information can be 
distributed over many HTML pages (in case of frames) 
and is not available on the proxy side unless the proxy 
stores the access history and establishes a session concept. 

4.2. Extensions of AdaWeb concept 

In order to improve the mobile WWW access, we have 
extended our system concept with new components. 
These components are: 

• Client Proxy including Client Monitor and Data De- 
compressor. 



# Data Compressor. 

• Resource Trader. 

4.2.1. Data Compression and client components 

The Data Compression/Decompression is related to 
the integration of a client-side component due to the 
usage of a proprietary coding algorithm which is not 
supported by standard browsers. Our coding algorithm 
is based on the GZIP coding scheme [18,19], but, instead 
of generating the whole dictionary, an initial dictionary 
depending on the transmitted content type is predefined 
[20]. This dictionary is known by the data compressor as 
well as the decompressor. The advantage is that the 
dictionary does not have to be transferred, thus avoiding 
the ineffective phase at the~beginning of the data com- 
pression. In this way, relatively small data files can be 
effectively compressed. 

The compression component of AdaWeb starts after 
the adaptation process is finished. Like the other compo- 
nents of the AdaWeb proxy, it communicates with the 
RIB to check which decompression possibilities the mo- 
bile client disposes of If an adequate dictionary for the 
current content type is supported on the client side, the 
compression starts. Otherwise, the data stream is sent to 
the client without modification. 

A compression algorithm as mentioned above necessi- 
tates decompression as a counterpart TTie decom- 
pression is one component running on the mobile client 
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Fig. 5. Components at the client side. 



and is integrated within a client-side proxy. On one side, 
this proxy transmits requests from the browser to 
AdaWeb. On the other side, it receives the adapted 
WWW content from AdaWeb and when the content is 
compressed it is decompressed before being forwarded to 
the browser. 

However, we do not only use the chent-side proxy for 
modification of the data transfer from AdaWeb to the 
proxy, but also for getting additional dynamic context 
information from the client. This information includes, 
for example, the battery life of the mobile device, the 
workload of its memory /processor or the current 
position of the user. A Monitoring Component is 
responsible for collecting this information and sending 
it to the Request Manager which appends it in^ the form 
of a cookie on a transmitted request to AdaWeb (see 
Fig. 5). 

4.2.2. Trader component 

When reaching a valid premise of a rule the Adapta- 
tion Component of AdaWeb executes the operations 
within the action part of the rule. The execution of an 
operation in this case means that the Trader Component 
is at first invoked with the name of the operation. Re- 
turned to the Adaptation Component, the result of this 
invocation is a service that can, at present, best perform 
the operation. The best service in our concept is the one 
which performs the desired operation in the shortest 
time. 

Therefore, the Trader Component needs to know how 
long a service would require for the execution of the 
operation. In order to achieve this, we will encapsulate 
each service with a Monitor Component. This compon- 
ent receives requests like that of the service itself, but 
instead of executing a task directly it is buffered into 
a FIFO-queue and is delivered to the service when it 
reaches the beginning of the queue. For each task the 
Monitor measures the execution lime and, taking these 
measurements into account, as well as the number of 
tasks inside the queue, it estimates the time in which the 
next received task will be finished. 




Fig. 6. Interplay of service monitor and trader. 



At first, we will start our development with a simple 
averaging as estimation and then compare the results 
with a more sophisticated model, where the estimation 
is based on a Kalman filter and considers dynamic 
variations. 

The result, the estimation of the execution time for the 
next task, is transferred from the Monitor to the Trader. 
The Trader manages similar services within a priority list 
ordered by the time value. When requesting a service by 
the Adaptation Component, the first service within the list 
is returned. Fig. 6 shows the interplay of the components. 

5- Integration of AdaWeb within mobile applications 

AdaWeb can manage a lot of dynamic context in- 
formation and is therefore suitable for context-aware 
WWW applications. This enables information access and 
information presentation taking into consideration the 
current situation of the user. The goal is to make the 
interaction with the WWW as simple as possible, so that 
the user can concentrate on the current task instead of 
the handling of the device. In this regard context in- 
formation helps to decide which and how the informa- 
tion will be presented. 

The location of a user is an important context para- 
meter, especially for mobDe application scenarios. For 
this reason the additional proxy component on the client 
side is connected to a GPS-receiver for detecting the 
current position. 

With this extension AdaWeb is one of the main com- 
ponents of our city information system, as the architec- 
ture shows (see Fig. 7). This system informs the user 
about his current position and allows him to make re- 
quests related to his environment; for example where the 
nearest restaurant is. 

AdaWeb is responsible for managing the context in- 
formation and adapting the WWW-based user interface 
of the system to the display capabilities of the mobile 
device. To fulfill the requirements it monitors the current 
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Fig. 7. Architecture of the WWW-based City Information System. 



position of the user. With the context information from 
Ada Web, the city information server generates the map 
where the current position of the user is marked with 
a circle. Furthermore, the map contains highlighted ob- 
jects that are interesting for the user. Depending on the 
capabilities of the device, the objects are displayed in 3D 
presentations or in the form of rectangles, which link to 
further information. 

In a further development phase, the system will send 
messages autonomously, if it deduces from an entry with- 
in the user profile that the user could be interested in it. If 
the user profile contains for example the key ^'interested 
in" which may refer to "sight seeing", a short text informs 
the user of any tourist attraction in the vicinity. When the 
user has arrived at his chosen destination, he is able to 
enjoy his sightseeing, as the information he needs is given 
in an acoustical form. 



6. Conclusion 

The vision of a simple and ubiquitous information 
access requires solutions for an efficient integration of 



mobile devices within the WWW infrastructure. The 
main problems are the restricted resources on the mobile 
computing device and the narrow bandwidth and unre- 
liability of the wireless link. 

In this paper we have presented a system concept 
enabling a context- aware adaptation for the information 
access and presentation within mobile WWW applica- 
tions. A rule-based system is used to evaluate dynam- 
ically the most appropriate adaptation strategy for the 
current context. The context is defined by user prefer- 
ences and device properties. The basis for the system is 
the Resource Information Base (RIB) that maintains the 
information about the device properties, user preferences 
and adaptation rules. 

The system has been developed as a single-proxy archi- 
tecture that performs the adaptation of the WWW access 
with the resources of hosts in the fixed network. This 
approach has the advantage that no changes have to be 
made on the browser at the client side. This means that 
every mobile computing device can use its standard brow- 
ser to gain access to arbitrary WWW-servers via Ada Web. 

First experiences with the core system show that 
Ada Web is a very promising solution and a first step in 
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the right direction to adapt arbitrary WWW content 
according to the properties of the end device and user 
preferences. In order to consider the aspects of data 
traffic, network latency and unreliability additional com- 
ponents on the client as well as on the proxy are needed. 
We have described in this paper how a client component 
can easily be integrated within the Ada Web system to 
extend the managed context information. The integra- 
tion of a compression and a specific location component 
are especially illustrated. Here, a locator for the Global 
Positioning System is used to monitor the location of 
a mobile user. It enables AdaWeb to utilise location 
information for the adaptation process within location - 
dependent applications. Moreover, we have presented 
a trader concept for AdaWeb that identifies the available 
resources for the adaptation process. The selection of free 
resources for the adaptation pipeline supports a scalable 
adaptation service by distributing the adaptation 
workload. 

Obviously, several interesting issues still remain open. 
Currently, implementations of several components, such 
as filters and compression concepts for further media 
representations and the trader concept are in progress to 
validate the AdaWeb framework. 

Besides the dynamic adaptation, one further strength 
of AdaWeb is its ability for customisation, because the 
mobile user can select the adaptation strategy with its 
preferences. The main goal is to enable an intuitive con- 
trol of the context adaptation process for the user via 
a user interface. This could be achieved through creating 
sets of rules, which are based on pre-defined mobile 
situations (e.g., the type of motion — on foot, by car, etc.) 
and pre-selected user options. 

We are confident that besides mobile devices other 
information appliances will also benefit from AdaWeb. 
One example is the presentation of Web content via 
AdaWeb on a TV set. 
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